1. Technical Field
This disclosure relates generally to web application security.
2. Background of the Related Art
Ensuring that modern software systems are free of security vulnerabilities is a daunting task. Such systems often comprise large amounts of code, including third party and remote components. Moreover, the measures that need to be taken to prevent potential attacks, in most cases, are far from straightforward, as they depend on the state of the application, the exact content of the (potentially malicious) data being processed, and the use(s) the application is about to make of that data. The problem is aggravated when it comes to web applications, which by design often feed on untrusted data in the form of user input. Also, web applications often make access to security-sensitive resources, such as databases, file systems or sockets. The problem of securing web applications against malicious attacks therefore has received significant attention.
Cross-Site Scripting (XSS), also known as script injection, is a web application vulnerability that allows malicious users to inject code into pages that are viewed by other users. In many classifications, it is recognized as a top web application vulnerability class. The most severe consequences of XSS issues are that attacker is able to make a legitimate user's browser perform operations that change application state on behalf of that user, or that make a user's browser disclose private data. Typically, cross site scripting attacks attempt to access cookies that the web application uses to implement security features. Cross site scripts, however, also may compromise security in other ways including, without limitation, tricking the user into supplying credentials to the attacker, causing a denial of service type of attack designed to hinder the server (e.g., loops to send emails, loops posting to a forum, or the like), causing a denial of service type of attack designed to hinder the client (e.g., purposefully implementing an infinite client-side processing loop), and delivering security cookies via web application rather than over secure connection.
To guard against cross-site scripting attacks, the web application must parse use input and rewrite any potentially problematic text. This processing may require significant resources. Also, this type of mitigation approach assumes the effectiveness of the parser. Any potential to circumvent the parser necessitates both fixing the parser and applying maintenance, thus incurring further development and administrative overhead.
There are several known methods to protect against an XSS attack. One approach is referred to an input filtering. This approach involves checking web application input for malicious data and rejecting or filtering it as needed. The input filtering method, however, cannot guarantee full protection, and it may be overly aggressive (to the point of being useless) if input data is used by web application in multiple contexts (e.g. HTML and Java Script). An alternative approach is to use client-side protection, whereby users equip their browsers with extensions that automatically detect attack attempts. The client-side approach, however, does not work properly with some types of XSS attacks, especially persistent XSS where injected code is not passed through input parameters. Yet another approach is referred to output escaping. XSS attacks happen when the application fails to escape its output and an attacker put HTML and/or Javascript on the site, which code then runs in the site visitors' web browsers. Output escaping stops this happening by making sure that the application never sends commands (HTML) when it only intends to send plaintext. To be implemented successfully, however, this solution requires significant attention from developers and an active approach from test teams, and it is difficult to implement if the application is a composite created with software from different vendors. Output escaping mechanisms also are difficult to maintain and automate.
One other approach to defeating script injection attacks implements a browser-enforced policy called Document Object Model (DOM) sandboxing. In this approach, the application structures its pages to identify content that might include malicious scripts. The possibly-malicious user content is placed inside of a <div> or <span> element that acts as a sandbox. Within the sandbox, rich content is enabled, but scripts are disabled. When invoked, a hook function examines the document in its parsed representation, namely, a DOM tree. Beginning at the DOM node of the script, the hook function inspects al of the nodes up to the root of the tree, looking for “noexecute” nodes. If such a node is found, the script is not executed. While this approach provides advantages, it is complex to implement and requires the application developer to write and maintain additional scripts within the application pages, thereby increasing development and support costs. Also, the technique does not provide protection against DOM-based XSS attacks.